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COMPUTfiR SYSTBK FOR DECXJkRINO APPIiICATZON DATA 

Field of the Invention 

The present invention relates to electronic data 
5 processing in general, and particularly to application 
prograimaing. 

Background of the Invention 

In the generally accepted model view controller (Mvc) 

10 design pattern used for developing application 
programs, the model represents the core of such an 
application program. The model can have multiple views, 
where each view displays information about the model to 
a user. A oontroller of the model receives events, for 

15 example, raised by a user interacting with a view to 
manipulate the model. The model can have multiple 
controllers and a controller can relate to multiple 
views . The model and the controller typically include 
application code. When changes occur in the model, the 

20 model updates all of its views. So called data binding 
is used for da.ta. transport between the view and its 
model or controller. For example, a table view can be 
defined to display data of a corresponding table that 
is stored in the model or controller. The table is used 

25 as data source for the table view (data binding) . For 
example, the table view can be replaced by a further 
view, such as a linked list, that binds against the 
same table. In this case the further view displays the 
table data without changing anything in the controller 

3 0 or the model . 

When building a software application, typically 
some predefined relationships exist between various 
data used by the application. For example, the 
relationships are defined through dependencies in a 
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relational database. However, for some data predefined 
relationships do not exist, for example, when no 
relationslxip is defined in a database or when it is 
data that refer to the model on the one hand and to the 
5 view on the other hand. Therefore, usually a major part 
of application coding is used to define the 
corresponding relationships and to enable the data 
transport, for example, from the model to the view. 

Further, at a given point in time an application 
10 has a specific state that reflects the current status 
of the interaction of the user with the application 
{e.g., on which view is the cursor of the application 
and which row of a specific table in the view has been 
selected by the user) . Typically, an application 
15 developer has to write application coding to memorize 
and administrate the state (e.g., by using state 
variables) . 

Further, when the user of a client-server system 
interacts with the client, typically the client sends a 

2 0 request to the server to rebuild a current page and the 
server sends the rebuilt page to the client. This may 
cause an unpleasant effect for the user in the form of 
a flickering picture on a display device of the client. 
Some client-servex systems support mechanisms to 

25 rebuild only mandatory components of the page and send 
only the corresponding delta information to the client 
to reduce flickering. However, to determine the delta 
information application specific coding has to be 
developed on both sides, the client and the server. 

30 Summary of the Invention 

To alleviate the problems of prior art systems the 
present invention provides methods, systems and 
computer program products to provide an excended mvg 
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design pattern for structuring data of an application 
in contexts that correspond to controllers . 

A computer system chat is used to develop and/or 
run applications according to the extended MVC pattern 
5 includes a model, at least one view and at least one 
controller. The model can have multiple controllers. A 
controller can control a view or further controllers. 
The at leaat one view presents the model. The at least 
one controller rela.tes to the at least one view and 

10 manipulates the model. The computer system further 
includes at least one context . The at least one context 
relates to the at least one controller and declares 
data of the application. The at least one context 
further declares data hierarchies that describe 

15 relationships between the data. 

Different types of context can be defined. A view 
context is assigned to a view controller. The lifetime 
of the view context /controller equals the lifetime of 
the corresponding view. in other words, the view 

20 context lives as long as the corresponding view is 
displayed. A custom context is assigned to a custom 
controller. A custom controller is one that has no 
views. The lifetime of a custom context can span the 
lifetime of multiple views. Therefore, a customer 

25 context can store data (e.g., data defining the 
interaction status) that are needed in multiple views. 

Context hierarchies can be defined. A view context 
can reference data from a custom context . This allows 
an efficient componentisation of the application 

3 0 because data can be accessed from a view through 
corresponding references to custom contexts instead of 
copying the data each time to the corresponding view 
context . 
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It is an effect of the present invention that less 
memory is needed to store an interaction status because 
redxindant data storage is eliminated. 

It is a further effect of the present invention 
5 that data are stored only once in an application. 
Therefore, program code redundancy that originates from 
using multiple variables for the same data in prior art 
systems is eliminated. This in^roves th® data 
consistency within an application. 
10 It is a further effect of the present invention 

that the data relationships are defined in a 
declarative way. Therefore, specific functions can be 
implemented without application specific program code. 
Examples of these functions are : 
15 filtering by using the data relationships; or 

identifying which data have been changed to 
determine the delta that needs to be sent from a server 
to a client . 

The aspects of the invention will be realized and 
20 attained by means of the elements and combinations 
particularly pointed out in the appended claims. It is 
to be understood that both the foregoing general 
description and the following detailed description are 
exemplary and explanatory only and are not restrictive 
25 of the Invention as described. 

Brief Description of the Drawings 

is a simplified block diagram of a computer 
system that implements an embodiment of the 
extended MVC design pat tern ; 
illustrates an example of a structure of a 
context at design time and at runtime; 
illustrates the context at runtime as a set 
of data instances ; 



PIG. 1 

30 

FIG. 2 
FIG. 3 
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5 



10 



5 



PIG. 4 illustrates an example of a node selection 

within the context at runtime 
FIGS. 5A,5B illustrate two alternative runtime 

implementations of context data instances ; 
FIG. 6 illustrates an example of context lifetimes 

for various context types; 
FIG. 7 illustrates mapping of contexts according 

to the present invention; and 
FIG. 8 illustrates a specific example of mapping 

contexts . 



Detailed Description of the Invention 

The present invention introduces the concept of context 
to the MVC design pattern . This will be referred to as 
IS extended MVC design pattern. 

FIG- 1 is a simplified block diagram of a computer 
system 900 that Implements an embodiment of the 
extended MVC design pattern. 

20 The extended MVC design pattern provides a context 

as a structured storage place for data that relates to 
a controller-. A context instance 304 relates (dashed 
line) to a controller instance 3 02. Context instances 
and controller instances will be referred to as 

25 contexts and controllers, respectively. The controller 
3 02 can manipulate a model 301 in response to an 
interaction of a user lo with the computer system 900. 
There can be further controllers (e.g., further 
controllers 302-a, 302 -b, 302-c) for manipulating the 

30 same model 301. The further controllers can have 
further contexts 304-a, 304-b, 304-c that relate 
(dashed lines) to the further controllers r 
respectively. The model 301 can have multiple views 
(e.g., views 303, 303-a, 303-b) that present the model 
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to the user 10. When the model 301 gets modified Joy at 
least one of its controllers it updates all of its 
views. Each view relates (dashed lines) to a 
controller. There can be controllers (e.g., controller 
5 3 02-c> that do not relate to any view. In one 
embodiment, a controller can relate to multiple views. 

PIG. 2 illustrates an example of a structure of a 
context 304 at design time and at runtime. In general, 

10 structure elements of the design time context structure 
are different from structure elements of the runtime 
context structure. 

An example of a design time context str\icture is a 
node hierarchy, wherein the structure elements of the 

15 node hierarchy can be nodes and attributes. The root- 
node of the node hierarchy represents the context 
itself. For example, the child nodes of the root node 
can be defined by the application. Child nodes of the 
root node will also be referred to as independent 

20 nodes. Child nodes of independent nodes depend on their 
corresponding parent node and will also be referred to 
as dependent nodes. 

A node has a node type . Elxamples of node types are 
value nodes and model nodes. A value node can maintain, 

25 that is, store and administrate, its own application 
data (transient application data) . The data can be, for 
example, scalar data, tables or structures. A model 
node includes a reference to a corresponding model that 
persists application data. 

30 The parent node can also have attributes. Each 

child node can include an arbitrary tree structure that 
includes further child nodes and/or attributes. 
Attributes are leaves in the tree structure. Attributes 
represent, for example, scalar data types, such as 
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Strings and integers or Java types (e.g., 
java.util -Date) . 

In the example of FIG. 2, at design time, the 
context 304 includes the independent node PN that 
5 includes the two attributes Al, A2 and that 1b the 
parent node of the dependent nodes CNl, CN2 . The second 
dependent node CN2 has two further attributes A3 , A4 . 
This structure defines a first node element 701 fox- the 
parent node FSi and a second node element 702 for the 

10 second child node CN2. The first node element 701 
includes information about the context structure with 
regards to the parent node PN. Xn other words, it 
summarizes all information that is available at the 
context structure level that is under the level of the 

15 parent node PN. The second node element 702 includes 
inf oxxnation about the context structure with regards to 
the second dependent node CN2. The context structure 
implies that the second node element 702 depends on the 
first node element 701. 

20 At rimtime, structure elements (e.g., nodes) 

represent a set of data instances. Nodes provide type 
information about object instancea bhat are maintained 
by Che node. Each node can have a node collection, 
wherein each element of the node collection has the 

25 same node element type. 

in the example of FIG. 2, at runtime, the parent 
node PN has a first node collection 4 01 that includes 
multiple runtime instances of the first node element 
701, Each runtime instance of the first node element 

3 0 701 can have a second node collection 402 of multiple 
runtime instances of the second node element 702 . A 
node collection can be en%>ty or has at least one 
instance of the corresponding node element. 

A node collection has a cardinality and a node 

35 collection type, such as list, tree, set or collection. 
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The node collection cardinality (cf. table 2) and Che 
node collection type (cf. table 1) can be declared at 
design time. An evaluation mechanism can be used to 
automatically evaluate the node collection of a child 
5 node at runtime when its parent node changes . 



Table 1: Examples of node collection types 



Value 


Meaning 


Collection 


forward-only iterator (cursor) without absolute 
positioning 


Set 


no duplicates, forward-only iterator without 
absolute positioning 


liist 


duplicates allowed, position available, list 
iterator, absolute positioning (indexed access) 



The application can use the cardinality of a node 
10 collection to restrict possible operations on a node 
(e.g. , prohibit indexed access to a node that has at 
most one node collection element) . 

Table 2: Examples of the cardinality of a node 
15 collection 



Value 


Meaning 


0. .1 


node collection can be empty, contains at most one 
element 


1. .1 


node collection always concains exactly one 
element . 


0. .n 


node collection can be empty or contain any number 
of elements 


1. -n 


node collection always contains at least one 
element . 



The content of a node collection can be determined 
in various ways . 

The node values of independent nodes can be set by 
20 initxalizer-s or event handlers or can be set through a 
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supply function. The supply function is called when the 
node ia accessed. To access a node, fox example, the 
node is queried for its data by application code or by 
a user interface (UI) element {of the view) that is 
5 bound to the node. 

Dependent nodes can get their values by using a 
supply function. For example, the node collection of a 
dependent node can became obsolete when a selection of 
its parent node chamges. In tliie case the dependent 

10 node is recalculated, that is, the content of its node 
collection is determined on a subsequent a.ccess. Xn. 
another example a representation instance is erea.ted 
for each dependent node of a parent node. The values of 
the representation instances are calculated when the 

15 corresponding parent node ia accessed. In other words, 
using representation instances enables a "load data on 
demand" or a "unload data when not needed" mechanism. 
Therefore, memoiry is used in an efficient manner. 

The content of a node collection can also be 

20 es^licitly set to a state, such as "invalid" or 
"unfilled". When the node is accessed the next time, 
the node collection content is determined again. This 
can be used to force a re-read of modified data when 
the modification (e.g., in the model) was not visible 

25 to the application runtime. 

FIG. 3 illustrates the context 304 at runtime as a set 
of data instances. The nodes of the context at runtime 
represent a framework -managed set of data instances 

30 (e.g., a java.sql .Recordset) . For example, data 
instances are returned 50 from a database or backend 
system 901 in response to a query (e.g., a structured 
query language (SQL) cfuery) that is sent 40 from the 
computer system 900 to the database/backend system 9 01 

35 when a node is accessed, for example, by an 
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application. Examples of backend systems are 
Eaiterprises Resource Planning systems. Customer 
Relationship Management systems, web server systems 
providing web services or any other system that stores 
5 application data. Accessing a node means requesting 
data from the corresponding model. This can result in a 
corresponding query request from the model to the 
database /backend system 901. Nodes provide type 
information dbout object instances that are maintained 

10 by the node. The type information can also be derived 
from the model. For example, if the parent node PN 
corresponds to a customer, its node collection 401 can 
include all orders for this customer. When the 
application accesses the parent node PN the computer 

15 system 90 0 can sent 40 a query to retrieve all orders 
of the customer from tbe corresponding database/backend 
system 901, Buch as a sales and distribution (SD) 
system or a customer relationship management (CRM) 
system. The retrieved orders (data instances) are then 

20 returned 50 to the computer system 900 context 404 to 
fill the corresponding data of elements of the node 
collection 4 01. 

FIG. 4 illustrates an example of a node selection 501 

25 within the context 3 04 at runtime. 

A node PN can maintain a node selection 501 within 
a node collection 401. Node selections are illustrated 
in FIG. 4 by a grid pattern for each element of the 
node collection that belongs to the node selection. The 

3 0 node selection 501 is a designated svibeet (one or more 
elements) of the node collection 401 of the node PN. 
The node selection 501 has a cardinality that is 
controlled by the cardinality of the selected nodes 
declared at design time (cf . table 3, below) . One 

35 specific element that plays a special role amongst the 
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elements of the node selection will be referred to as 
the lead selection element. 

For example/ if the node PN corresponds to a 
specific customer, the first node collection 401 can 
5 include all orders of the customer. 

The lead selection of the node collection can be 
by default the first order of the customer. In this 
case, the second node collection 402 can include all 
order items of the selected order. 

.0 

Table 3 : Examples of the cardinality of a node 
selection in dependence of the node (collection) 
cardinalities of the corresponding node elements of the 
selection 



Value 


Meaning 


Node Cardinality 


0. .1 


single selection (= lead 
selection} , can be empty- 


Any 


1. .1 


single selection {= lead 
selection) , always contains 
one element 


only 1 . . 1, 1 . .n 


0. .n 


multiple selection; can be 
empty; if not empty one 
element is designated as the 
"lead selection" 


only 0 . . n , 1 . . n 


1 . .n 


multiple selection. One 
selected element is 
designated as the "lead 
selection" 


only 1 . . n 



If the node selection is not empty at runtime, one 
of the elements of the node selection is designated as 
the lead selection element . The lead selection element 
can be accessed from controller code, tri elements can 
be bound against the attributes of the lead selection 
element and the content of a child node depends on the 
lead selection element of its parent node. For example. 



EmPfan«szeit 3l.0kt. 14:44 



31-OKT-2002 1 4 : 57 



SAP RG WPLLDORF 



+49 6227 764433 S. 20/49 



2002P10032EP 12 

the node selection 501 can correspond to a selection 
that results from an user action (e.g., the user 
selects the second order out of a list of orders.) This 
automatically triggers an update of the second node 
5 collection 4 02 with, for example, all order items of 
the second order. The second node collection 402 can 
have a further node selection 502. A node selection can 
also include multiple elements of the corresponding 
node collection. 

10 Node selection and lead selection element are 

bindahle node properties in the sense that DI elements 
can represent a node selection (e.g., as selected lines 
in a table control) and also modify it (e.g., 
selecting/deselecting an item in a table control 

15 adds /removes the corresponding element to/from the node 
selection) . Node selections can exist on their own. A 
selection made by a user can be represented as a node 
selection and a node selection can be visualized in a 
Ul element . 

20 A context can include a flat set of child nodes 

(independent nodes) each one independent from the 
others. Each independent node can have further child 
nodes (dependent nodes) . While the content of 
independent nodes can be defined by the application, 

25 the content of a dependent node depends on the lead 
selection element of its parent node. The application 
defines how the content of the dependent node depends 
on the parent node's lead selection element by 
specifying a corresponding supply function. For 

3 0 ex:ample, a supply function can be used in case a 
Specific order (e.g., node selection 501) of a customer 
is selected and only order items that are not on stock 
Should be included in the second node collection 4 02. 
in other words, the relationships between data that are 
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declared in the context 304 at design time can be used 
to filter data at runtime. 

For example, ttie supply function can be defined in 
such a way that it always returns the same value for 
5 the same selected node element and does not take into 
account changes in the returned data. In other words, 
the application runtime can decide not to call a supply 
function again with the same argtunents when it is 
called a second time within the lifetime of the 

10 application. 

For example J when a parent node (e.g., an order) 
is boimd to a new node collection, the content of all 
of its child nodes (e.g., order items) becomes 
"invalid". When a node is accessed and its content 

15 (node collection) is "invalid", its content is 
determined again, for example, by calllng^ a 
corresponding supply fiinctlon 601 to supply content for 
the node. 

Supply functions CeUi be declared as methods in the 
20 corresponding controller 302. The following pseudo code 
shows an exanqple of the signature of a supply function; 

Pseudo code exeunple: 
Collection supplyPunot ion (Node node, NodeElement 

25 parent Element) ,- 

When the application is generated, program code is 
generated that calls the declared method when content 
for a node is Co be supplied 60. 
30 Embodiments of a supply function can have one or 

more of the following features: 

■ Node elements included in a returned node collection 
match the type of the corresponding node (e.g., a 
node element created from the node or from a mapped 
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node or from a corresponding model class, if tlie node 
is a model node) 

■ Tiie supply function returns enough data to match the 
declared cardinality of the node. 

5 ■ The returned node collection depends on paz-ameters of 
the supply function. The supply function is called a 
second time within the lifetime of an application 
when at least one of the parameters is changed. 

■ The supply function can also be loaded on demand by 
10 t:he a.pplicat:xon. 

PIGS. 5A and SB illustrate two alternative runtime 
implementations of context node data instances of a 
context 304 -a. 

15 in a first implementation (cf. FIG. 5A) , a 

dependent node <e,g.j node B) can be represented as a 
single node instance whose node collection changes 
whenever the parent node's (e.g., node a) node 
collection or lead selection element changes. For 

20 exanple, for a single node instance, content (node 
collection) can be maintained for the current lead 
selection of the parent node only. This reduces the 
amount of used system resources, such as main memozy, 
and it enables static binding. Static binding means 

25 that the node binds co a "class" of the node instead of 
binding to a named node instance . A node according to 
the first implementation will be referred to as a 
singleton node. 

FIG. 5A shows an example of a context structure of 

30 context 304-a at design time. Node A has a node element 
NE (A) , node B has a node element NB(B) and node c has a 
node element NE(c:), wherein each element includes child 
nodes and/or attributes. At runtime, in case of a 
singleton node implementation, a node collection NC(B) 

35 of node element NE(B} instances is only maintained for 
the lead selection of the node collection NC(A) . 
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Further, a node collect:ion NC(C) of node element NE(C) 
instances is only maintained for tne lead selection of 
the node collection NC(B) . 

In a second implementation (cf. PIG. SB) a single 
5 node instance of the node (e.g., node B) exists for 
each instance in the parent node collection (e.g., node 
collection NC(A)). All single node instances can be 
accessed directly. For example, a iruntime 
implementation can create and fill single node 

10 instances lazily (by loading data on demand) to reduce 
resource usage . xn the second implementation an 
application can also access data of child nodes that do 
not correspond to the parent node's lead selection 
element (e.g., read address fields for business partner 

15 No. 5 instead of the address fields for the currently 
selected business partner No. 3) . A dependent node 
according to the second implementation will be referred 
to as a non- singleton node. 

FIG. 5B is based on the context structure 304-a at 

20 design time as described under FIG. 5A. It shows an 
example of a runtime structux-e of context 304-a 
according to the second implementation. Each instance 
in node collection NC(A} can have a node collection 
NCI (B) to NC3 (B) . Further, each insteuice of node 

25 collections NCI (B) to NC3 (B) can have a node collection 
NCI (c) to NC5 (C) . Empty node collections are not shown 
in the example. 

The information if a node is a singleton or non- 
singleton node can be stored in a node property 

30 "singleton" (cf. table 4, below). 

If a non^singleton node acts as the parent node of 
a singleton node, the singleton node is not a singleton 
node with regards to the context. That is, for each 
instance of the non- singleton parent node thez-e exists 

35 one Instance of the singleton child node. If the child 
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node is a singleton node with regards to the context, 
then its parent node may change depending on its 
grandparent node's lead selection element. 

A framework keeps references to all created 
5 instances of a child node xintil the parent node's 
collection changes. This enables a client in a client- 
server computer system to remember data from previously 
received child node instances and modify this data 
later. The server keeps this data and has, at all 
10 times, a consistent picture of which data is in the 
current context ( = context of the current view) . 



Table 4 ; node property singleton 



Value 


Meaning 


True 


a single instance of the node exists per parent 
node and the content of the node changes when the 
parent node • s lead selection element changes . 


False 


one instance of the node exists per node element in 
the parent node's node collection. The content of 
an instance does not change. 



All instances of a child node can be accessed 
through a typed context application programming 
interface (API) . 

If the parent node is a singleton node, only a 
single instance exists and can be accessed and its 
content depends on the parent node's node collection 
and lead selection element. 

For example, at design time, a tree structure is 
declared including an independent node "Customers" that 
has a child node "Orders" and the child node "Orders" 
has a further child node «0rderlt ems" . Each customer 
can have multiple orders and each order can have 
multiple items. This is reflected in a corresponding 
context toy declaring chiid nodes belonging to each 



20 
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element of the parent node so that' each element has a 
collection of its own. 

FIG. 6 illustrates an example of context lifetimes for 
5 various context types- 

There are at least two types of controllers and 
correspondingly two types of contexts: view 
controllers/view contexts and custom controllers/custom 
contexts . 

10 A view controller relates to a corresponding view. 

The lifetime of the view controller equals the lifetime 
of the corresponding view, that is, the time the view 
is displayed. A view context relates to the view 
controller and has the same lifetime. UJ elements of 

15 the view can bind to the view context. When eacecuting 
an application (e.g., APPLICATION A) that is built 
according to the extended MVC design pattern, typically 
a sequence of multiple views (e.g., VIEW l, view 2, 
VIEW 3, VIEW 4) is presented to a user. The user 

2 0 interacts with the application program through the 

various views. The various views can raise events that 
cause the related view controllers to determine which 
view is presented when and where. That is, some views 
and, therefore, the related view contexts can ha-ve a 
25 Short lifetime. 

In the example of PIG. 6, APPLICATION A starts at 
TAl and ends at T7^. When the application starts, 
VIEW 1 and VIEW 2 are presented to the user 
simultaneously. At TVl, the corresponding view 

3 0 controllers determine that the presentation of VIEW 1 

and VIEW 2 needs to be replaced by a presentation of 
VIEW 3. At TV2, the corresponding view controllers 
determine that the presentation of VIEW 3 needs to be 
replaced by a presentation of VIEW 4. The views view i 
35 to view 4 relate to the view contexts VIEW CONTEXT 1 to 
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VIEW CONTEXT 4. That is, the data that is stored in 
each view context has the same lifetime as the view 
that binds to the data. 

Some data need to be stored over the lifetime of 
5 multiple views. For this purpose, a custom context can 
be defined, A custom context relates to a. custom 
controller of the model. For example, a custom 
controller is implemented as view independent, 
application process oriented coding. The lifetime of a 

10 custom context can be defined in such a way that it 
spans the lifetime of multiple views. 

In Che example of FIG. 6, custom context i is 
defined to span the lifetime of the views VIEW i to 
VIEW 3. CUSTOM CONTEXT II is defined to span the 

15 lifetime of the views VIEW 3 and VIEW 4 . 

A specific example of a custom context is an 
application context, which lives over Che lifetime of 
the application, that is, over the sequence of all 
views of the application. However, in the case of a 

20 custom context, the application decides about its 
lifetime, whereas in the case of an application 
context, a framework can decide about the lifetime of 
the application context because the framework knows 
when an application starts (TAi) and when it ende 

25 (TA2) . Therefore, the framework can control an 
application controller that is assigned to the 
application context . 

PIG. 7 illustrates mapping of contexts according to the 

30 present invention. 

Because UI elements (e.g., UI elements 95i, 952) 
of views (e.g., VIEW 1, VIEW 2) that are used in a user 
interface (UI) 950 bind 81, 82 to view contexts (e.g., 
VIEW CONTEXT 1, VIEW CONTEXT 2) and long living data 

35 can reside in custom contexts (e.g., CUSTOM CONTEXT I), 
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an embodiment of the present invention enables mapping 
91, 92 of nodes/attributes of view contexts or custom 
contexts CO nodes /at tributes of custom contexts. In 
othex- words, nodes and attributes of view contexts or 
5 custom contexts can reference type -compatible nodes and 
attributes in other custom contexts. Nodes can also be 
mapped to other nodes within the same context . Node 
mapping reduces the need for copying data between 
several contexts by enabling a node Nl of a first 

10 context (e.g., a view context, such as VIEW CONTEXT 2, 
or a custom context) to reference 91 a node Nl < of a 
second context (e.g., a custom context, such as CUSTOM 
CONTEOtT 1, or an application context) , where the node 
Nl ' of the second context has or references the data. 

15 The same is tirue for attributes. 

Therefore, the data can be manipulated in a 
custom/application context and each view context that 
references the custom/ application context provides its 
view with the current data stored in the 

20 custom/application context. Mapping contexts can span 
multiple context levels. That is, a custom context can 
reference a further custom context. Therefore, context 
hierazTchies can be created (cf . FIG. 9) . 

For example, related data can be collected in a 

25 dedicated custom context. The binding to this data is 
implemented by using a view context that is mapped to 
the custom context accordingly. 

The extended MVC pattern , enables an application 
developer to quickly modify an application wliile 

3 0 maintaining consistency of the application. For 
example, in some cases rearrangement of views or UI 
elements can be achieved without modifying the 
corresponding controller code. This provides a way for 
an application developer to better structure 

3 5 applications in light of potential functional 
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enhancements or changes. For example, reusing a field 
that already exists on one view in other views can be 
achieved by defining the corresponding mapping while 
the corresponding controller code stays valid. 
5 The following examples explain various features of 

context mapping that can be implemented with the 
present invention. 

First example: 

10 If a node M ("Mapped Node") is mapped to a node O 

("Origin Node"), node M maps its node collection to 
node O's node collection. The node selections of nodes 
M and O can be mapped. Node M can also maintain its own 
node selection on node O's node collection. 

^5 For example, the node collection cardinality of 

node M equals that of node O (e.g., by inheritance). 

The selection cardinality can be inherited from 
o^iffin node O. Node M can override the node cardinality 
inherited from node O. 

2 0 If node O is a singleton node, node M is a 

singleton node, too. If node O is a non-singleton node, 
node M can be a singleton or non-singleton node. If 
node M is a non- singleton node it shares the same 
parent node collection with node O. If node M is a 
25 singleton node, then the collection of node M follows 
the instance of node O that belongs to the lead 
selection of node O's parent node. 

For mapped nodes. the content of the node 
collection can be defined by the node collection of the 

3 0 origin node. 

Second example : 

An independent node can always be mapped. It can 
be mapped to any other node in cue same context or to 
35 any other node in another custom context (as long as no 
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cycle is formed with regards to parent -child and 
mapping relationships) . 

A child node of a mapped node can be unmapped. In 
this case its content: can be determined by the supply 
5 function mechanism. 

When a parent node is mapped to a further parent 
node, a child node of the parent node can be mapped to 
a further child node of the further parent node. In 
other words, if node W is a child of node X and node Y 
10 is a child of node Z, node W can be mapped to node Y i£ 
node X is mapped to node Z . 

If a child node of a mapped node is mapped tio a 
further child node of the corresponding origin node, 
then either the mapped node maps to the node selection 
15 of the origin node or the origin node is a non- 
sxngleton node. This avoids a conflict between the 
dependencies implied by tbe parent/child relationship 
and the mapping relationship tlxat results from mapping 
a selection of a child node o£ an unmapped node. 

20 

FIG. 8 illustrates a third, specific example of 
mapping contexts. 

Two windows 950-1, SSO-2 can be displayed at 
runtime on a client of a client- server system. For 

25 example, the windows are part of a user interface of an 
application and are displayed on a conventional display 
device (e.g., monitor) of the client, a page that is 
displayed may include one or more view assemblies. 

The first window 950-1 displays view assembly MAIN 

3 0 that includes view A and view B. The second window 
displays view assembly POP UP that includes view D. The 
following description refers to definitions and 
declarations at design time. The views in the view 
assemblies include Ul elements which are bound to the 

35 view contexts of the corresponding views. The binding 
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is illustrated by bended arrows with a bullet point at 
the origin of the arrows. UI elements of views A, B, D 
are bound to view contexts A, B, D, respectively. The 
UI element in view A is a table having two columns. The 
5 four UI elements of view B can be diaplay/input fields 
that have a relationship to the Cable of view A. The UI 
elements of view D correspond to a title of the pop up 
and four further input/display fields. 

The view contexts A, B, D include node/attribute 

10 hierarchies for maintaining the data of the 
cozTzresponding view. Modes and attributes can derive 
their state from nodes/attributes of custom contexts 
(e.g., custom contexts 1, 2) that belong to controllers 
(e.g., custom or application controllers) other than 

15 the corresponding view controllers. This enables 
maintenance of the data without redundancies. Further, 
it can be used for a method for synchronizing data 
dependencies amongst multiple views. 

In the example of PIG. 8, view context A and view 

20 context B include one independent node each, which is 
illustrated as the top-level node of the corresponding 
context structure. The independent node of view A holds 
information about which record set is to be used for 
the table and about the current position within the 

25 record set. Both independent nodes are mapped to the 
corresponding independent node in custom context 1 . 
This means that view A and view B share a common data 
source (e.g., the record set) provided by the commonly 
used node of custom context l. Therefore, the record 

30 set displayed in the table of view A Is also used as 
the landerlying record set for view B. View A displays 
two columns of the record set, whereas view B displays 
three fields of a selected row of the record set . This 
is represented by the UI elements illustrated by a grid 

35 pattern. The three fields in view B can also serve as 
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input fields to update the xznderlying record set. View 
B displays a further- field not related to the record 
set. 

The declaration of data relationships through 
S contexts leads to redundancy free data transport from 
the server to the client and allows the application to 
synchronize the table of view A with the input in view 
B. It also allows an application developer to use the 
current selection in a custom controller without 

10 needing to know how the selection was made (e.g., by 
using a table view UI element, or a dropdown list til 
element or any other UI Element able to make a 
selection in a list) . This decreases the dependency of 
application logic from presentation logic. 

15 Context mapping can also be used to open a 

menu/list (e.g., view D in the view assembly POP UP), 
which can display data based on the current selection. 
No transport code is necessary and no selection 
parameters need to be passed. 

20 In the example of fig. 9, the last two attributes 

of view context D are mapped to corresponding 
attributes of custom context 2. Because the last 
attribute of view context B maps to the same attribute 
of custom context 2 as the next to last attribute o£ 

25 view context D, the content of the upper input /display 
field in view B equals the content of the upper 
input/display field in view D. No transport code for 
transporting data from view B to view D is necessary to 
achieve this. 

30 The last attribute of view context D is mapped to 

the last attribute of custom context 2 which again is 
mapped to the next to last attribute of custom 
context 1. This illustrates that multilevel context 
hierarchies can be built. Multilevel context 

35 hierarchies are useful to package data according to 
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their lifetime because, aa explained in reference to 
PIG. 6, each context can have a different lifetime. 
Storing data only once in the context hierarchy and 
using mapping to access the data through multiple 
levels of the context hierarchy avoids redundant 
storage of data and, therefore, reduces main memory 
consumpt ion , 

An embodiment of the present invention can be 
implemented by using a computer system that has at 
least a memory and a processor. The computer system can 
communicate with further computer systems over a 
network (e.g., a wide area network (WAN), a local area 
network (LAN). the internet.) A computer program 
product that can be loaded into the memory of the 
computer system includes instructions that when 
executed by the processor causes the computer system to 
perfonn steps according to the present invention. 

The invention can be implemented in digital 
electronic circuitry, or in computer hardware, 
firmware, software, or in combinations of them. The 
invention can be implemented as a computer program 
product, i.e., a computer program tangibly embodied in 
an information carrier, e.g., in a machine -readable 
storage device or in a propagated signal, for execution 
by, or to control the operation of, data processing 
apparatus, e.g., a programmable processor, a computer, 
or multiple computers. A computer program can be 
written in any form of programming language, including 
compiled or interpreted languages, and it can be 
deployed in any form, including as a stand-alone 
program or as a module, component, subroutine, or other 
unit suitable for use in a computing environment. a 
computer program can be deployed to be executed on one 
computer or on multiple computers at one site or 
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distributed across multiple sites and interconnected by 
a commimication network. 

Method steps of the invention can be performed by 
one or more programmable processors executing a 
5 computer program to perform functions of the invention 
by operating on input data and generating output . 
Method steps can also be performed by, and apparatus of 
the invention can be implemented as, special purpose 
logic circuitry, e.g., an FPGA {field programmable gate 
10 array) or an ASIC (application- specif ic integrated 
circuit) . 

Processors suitable for the execution of a 
computer program include, by way of example, both 
general and special purpose microprocessors, and any 

15 one or more processors of any kind of digital computer. 
Generally, a processor will receive instructions and 
data from a read-only memory or a random access memory 
or both. The essential elements of a computer are a 
processor for executing instructions and one or more 

20 memory devices for storing instructions and data. 
Generally, a con^uter will also include, or be 
operatively coupled to receive data from or transfer 
data to, or both, one or more mass storage devices for 
storing data, e.g., magnetic, magneto-optical disks, or 

25 optical disks. Information carriers suitable for 
embodying computer program instructions and data, 
include all forms of non- volatile memory, including by 
way of example semiconductor memory devices, e.g., 
EPROM, EEPROM, and flash memory devices; magnetic 

3 0 disks, e.g., internal hard disks or removable disks ; 
magneto -optical disks; and CD-ROM and DVD-ROM disks. 
The processor and the memory can be supplemented by, or 
incorporated in special purpose logic circuitry. 

To provide for interaction with a user, the 

35 invention can be implemented on a con^uter having a 
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display device, e.g., a CRT (cathode ray tube) or LCD 
(liquid crystal display) monitor, for displaying 
information to the user and a keyboard and a pointing 
device, e.g., a mouse or a trackball, by which the user 
5 can provide input to the computer. Other kinds of 
devices can be used to provide for interaction with a 
user as well; for example, feedback provided to the 
ueer can be any form of sensory feedback, e.g., visual 
feedback, auditory feedback, or tactile feedback; and 

10 input from the user can be received in any form, 
including acoustic, speech, or tactile input. 

The invention can be implemented in a computing 
system that includes a back-end component, e.g., as a 
data server, or that includes a middleware component, 

15 e.g., an application server, or that includes a 
front -end component, e.g., a client computer having a 
graphical user interface or a Web browser through which 
a user can interact with an implementation of the 
invention, or any combination of such back-end, 

20 middleware, or front-end componenta. The components of 
the system can be interconnected by any form or medium 
of digital data commvmication, e.g., a communication 
network. Examples of communication networks include a 
local area network (*IJ\N") and a wide area network 

25 ("WAN"), e.g., the Internet. 

The cornputing system can include clients and 
servers. A client and server are generally remote from 
each other and typically interact through a 
communication network. The relationship of client and 

30 server arises by virtue of computer programs running on 
the respective computers and having a client -server 
relationship to each other. 

The invention has been described in terms of 
particular embodiments. Other embodiments are within 

3 5 the scope of the following claims. For example, the 
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Steps of the invention can be performed in a different 
order and still achieve desirable results. 
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A computer system (900) comprising a model (301) , 
at least one view (3 03) and at least one 
controller (302) ; the at least one view (301) for 
presenting the model (301) ? the at least one 
controller (302) relating to the at least one view 
(301) eUid for manipulating the model (302) ; 
characterized in that : 

the computer system (900) further comprises at 

least one context (3 04) ; and 
the at least one context (304) relates to the at 

least one controller (302) and, at design 

time, declares data of an application that 

are used by the view (30i) . 

The computer system Ooo) of claim 1, wherein the 
at least one context (304) further declares at 
design time a context structure that describes 
relationships between the data of the application. 

The computer system (900) of claim 2, wherein the 
context structure has at least one independent 
node . 

The computer system (900) of claim 3, wherein the 
at least one independent node has at least one 
attribute. 

The computer system ($00) of claim 3 or 4 , wHerein 
the at least one independent node has at least one 
dependent node. 

The computer system (900) of claim 5, wherein a Ui 
element of the view binds to the context 
structure . 
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7. The computer system (900) of any one of the claims 
1 to 6, wherein the at least one controller (302) 
is a view controller and the at least one context 
(304) is a view context. 

5 

8. The computer system (900) of claim 7, wherein the 
lifetime of the view context (304) equals the 
lifetime of the view (303) . 

10 9. The computer system (900) of claim 7, further 
comprising a custom context that relates to a 
custom controller. 

10. The computer system (900) of claim 9, wherein the 
15 lifetime of the custom context spans the lifetime 

of the view (303) and the life time of at least a 
further view of the application. 

11. The computer system (900) of claim 10, wherein the 
20 custom context has at least one child node. 

12. The computer system (900) of claim 11, wherein the 
at least one child node of the custom context 
includes the data of the application. 

25 

13. The computer system (900) of claim 11, wherein the 
at least one child node of the custom context 
references the model (301) that stores the data of 
the application. 

30 

14. The computer system (900) of claim 12 or 13, 
wherein the at least one child node has at least 
one child node attribute. 

35 IS. The computer system (900) of claim 11, wherein the 
at least one independent node of the view context 
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is mapped to the at least one child node of the 
custom context . 



16. The computer system (900) of claim 5, wherein the 
at least one independent node is mapped to the at 
leaat one dependent node. 

17. The computer system (900) of claim ll, wherein the 
at least one dependent node of the view context is 
mapped to the at least one child node of the 
custom context. 

18. The computer system (900) of any one of the claims 
1 to 17, wherein the declared data of the 
application have a type selected from the group of 
scalar data type, table data type or structure 
data type. 



19. A computer program product comprising instructions 
that when loaded into a memory of a computer 
system (900) cause at least one processor of the 
computer system (900) to declare application data; 
the computer program product comprising: 
a model (301) , at least one view (303) and at 
least one controller (3 02); the at least one 
view (301) for presenting the model (3 0i) ; 
the at least one controller (302) relating to 
the at least one view (3 01) and for 
manipulating the model (302) ; and 
at least one context (304) that relates to the at 
least one controller (302) and, at design 
time, declares data of an application that 
are used by the view (30i) . 
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20. The computer program product of claim 19, wherein 
the application data have a data type selected 
from the group of scalar data type, table data 
type or structure data type. 

5 

21. A computer program product comprising instructions 
that when loaded into a memory of a computer 
system (900) cause at least one processor of the 
computer system (900) to perform according to the 

10 con^uter system (900) of claims 1 to 18. 
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COMPUTER SYSTEM FOR DECLARINQ APPLICATION DATA 

Abstract of the Invention 

5 A computer system (900) comprises a model (301) , at 
least one view (303) and at least one controller (302) . 
The at least one view (3 0l) presents the model (301) . 
The at least one controller (302) relates to the at 
least one view (3 01) and manipulates the model (302) . 
10 The computer system (900) further comprises at least 
one context (304) . The at least one context (304) 
relates to the at least one controller (302) and, at 
design time, declares data of an application that are 
used hy the view (301) . 

15 

FIG. 1 
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